SciTech/Scitech_FTP.zip/Scitech/SciTech MGL 4.05/projects.txt

Text File | 2018-01-25 | 20KB | 410 lines

                     SciTech MGL Graphics Library
                            Version 4.05

                 Cool Projects and Things To Be Added
                             May 12 1998


What is this document for?
--------------------------

This text document is intended to provide an overview of some of the
neat projects that could be worked on within the SciTech MGL to make
it a better product. If you are interested in working on any of these
projects, log onto news.scitechsoft.com and check out the
scitech.mgl.developer newsgroup. There may be other people working on
in the same area and you could contribute to this work.

If you have any other ideas for cool projects for the SciTech MGL, let
us know and we can add them to this list.

Blitting Functions
------------------

 . Add support for stretching in ModeX modes, using a simple stretch to
   a temporary buffer and then blit to the screen using the ModeX
   putScanLine functions.

 . Add support for MGL_flipBlit and MGL_mirrorBlit functions that will
   do a blit of a bitmap with a flip in the vertical direction or a mirror
   in the horizontal direction. Most useful for sprite based games. We
   would also need to implement transparent versions of these functions.

 . Add support for stretching with transparency. Currently the MGL will
   only support stretching without transparency and vice versa.

 . Add support for transparent blitting between device contexts of
   different pixel depths and pixel formats (ie: a translated, transparent
   blit). Currently the MGL requires that the pixel formats and color depth
   be the same for transparent blits.

 . Add faster, optimised C code for implementing special case translated
   blits. The most obvious candidate would be to implement fast 8-bit to
   15/16/24/32 blitting functions optimised for each case, since this
   is a good color depth for sprites. Currently the code to handle 8-bit
   to higher color depth translates goes through a single generic module
   in EMULATE\EM_TRANI.C

 . Add support for stretch blitting from 4 bit DC's to 15/16 bit DC's.
   Currently the MGL only handles stretching from 8 to higher color depths,
   but not 4 bit.

 . In order to provide better support for downloading of sprite data to
   hardware we could provide new functions to create special bitmaps
   allocated in offscreen memory on the graphics card. The offscreen memory
   manager from the Game Framework Sprite Library could then be merged
   into the main MGL libraries, and use either that or DirectDraw to manage
   the surfaces when we create them.

   Currently the SciTech MGL can only allocate a single, rectangular
   offscreen bitmap when running under DirectDraw, and on newer cards we
   could use DirectDraw to allocate smaller offsceen bitmaps for us more
   efficiently (ie: similar to the linear offscreen device contexts in the
   MGL).

 . Add a new MGL_bitBltRegion() function that would perform a normal BitBlt,
   but the blt will be clipped to the passed in region to the source
   device context. This can then be used for doing very fast blts of
   arbitrary areas for overlays etc. It could also be done in hardware
   using the blitter to move each scanline, which would work well for
   non-transparent blitter hardware.

   If we added a new MGL_bitBltBatch() function to allow blitting of a
   batch of rectangles, then we could layer the above function directly
   on top of that (for hardware accelerators). Then we could add a new
   bltBatch function to the VBE/AF device drivers to full handle multiple
   small blts very quickly (might make it very fast for transparent cockpit
   overlays etc).

Internal Rendering Functions
----------------------------

 . New integer ellipse algorithm to replace the current floating point
   routine that is a place holder. The old integer ellipse algorithm
   suffered from overflow in the decision variables (4*A^3 is a large
   number when A gets about about 800; A is the diameter of the ellipse),
   so the decision variables are now floating point. I am sure a better
   algorithm could be implemented that would solve this problem.

 . Add support for portait display capabilties so that the coordinate
   system for the MGL could be turned on end (either left or right) for
   a tall skinny display. For most of the rendering functions this would
   be easy, since all you need to do is swap the coordinates. The MGL
   text functions already support drawing in any 90 degree angle so that
   is easy. The biggest change would be new bitmap blitting functions that
   will do on the fly conversions between horizontal and vertical scanlines
   when blitting the bitmaps to the screen.

 . Add support for color mouse cursors. Currently the MGL only supports
   single color mouse cursors, and color mouse cursors would allow you to
   do cool things like have animated cursors playing while loading data
   from CD-ROM or whatever.

 . Change the mouse cursor rendering, to copy from the screen to a small
   scratch buffer, render the mouse cursor image to this system buffer and
   then blit the result to the screen. This will result is perfectly smooth
   mouse cursor motion that will totally eliminate any flicker.

 . Add support for 32x32 or larger patterns rather than the default 8x8
   bitmap pattern support.

 . Add support for fat elliptical arc rendering. We can do this quickly by
   computing an elliptical region and chopping out the wedge, although
   using regions may be a little slow.

 . Add support for round cornered rectangles.

 . Add support for scaling monochrome bitmaps to any size during rendering.
   Perhaps what we really need to do is add support for a mono stretchBlt
   routine that will actually stretch a mono bitmap to the display. Hence
   the bitmap will not need to be changed, just the code that does the
   blt operation.

 . Add code to align the bitmap pattern origin to a new location so
   that pattern fills can be done properly allowing the pattern to be
   aligned to any starting pixel coordinate. Currently the pattern is
   always locked to the global screen coordinates.

 . Add support for high speed pixmap rendering code. Basic pixmap (ie:
   color pattern fills) has been implemented in C for the library code,
   but none of it has been optimized yet).

Device Driver Functions
-----------------------

 . Add support for rendering directly to the surface of a window using
   either DCI (for Windows 3.1, Windows 95 and Windows NT) or DirectDraw
   (Windows 95 and Windows NT). Once this is implemented, it will be possible
   to use the MGL rendering functions to draw directly into a window for
   transparent bitmap rendering as well as implement front buffer rendering
   for OpenGL.

   The only complication with this is that rendering to the window can be
   complicated if the window is obscured by other windows, since we then
   need to handle the clip regions properly. In order to get around this
   problem, we can probably have an MGL function that will allow the app
   programmer to determine if the window is obscured, and if so do all
   rendering to a system memory back buffer and blit that to the screen
   (the blit will of course be correctly clipped).

Stereo LC Shutter Glasses Support
---------------------------------

 . Add Stereo support into the Game Framework. The MGL API itself is
   currently Stereo Enabled, but the Game Framework has yet to have
   stereo support added.

 . Update the MGL OpenGL bindings to properly support stereo. Most of
   the work for this has already been done, but stereo has not yet been
   tested when using the OpenGL libraries (only the regular MGL code).

 . Add Stereo support to the SGI SkyFly OpenGL sample program, as well
   as some of the other OpenGL samples. The best way to do this would
   be to include a -stereo command line switch to enable stereo in the
   standard sample program.

 . Add support for software stereo for systems that dont have hardware
   stereo page flipping or hardware stereo syncing. This needs to be
   done using a timer driven interrupt (using the real time clock I
   believe) for the DOS environment, and a VxD in Windows 95 based on
   the same principle.

   Perhaps some of the Stereo LC shutter glasses manufacturers would like
   to step up to the plate and take a look at adding software stereo
   support to the MGL?

Region Algebra Functions
------------------------

 . Add support for the missing polygon region functions, elliptical arc
   region functions and other region generation primitives.

 . Modify the segment definition to include both X1 and X2 coordinates in
   the same segment and re-write the underlying algebra routines. This
   will make the memory requirements significantly smaller for complex
   regions and will make it faster (but the algebra routines will
   be more complicated).

 . Add support for clipping all output to a selected clip region. This
   could probably be implemented by using a small driver routine that
   would hook between the API call and the device driver call when a
   complex clip region is selected, that would select each rectangle
   in the clip region as the current driver clip rectangle and then
   re-issue the driver rendering command over and over until the region
   has been traveresed.

Bitmap Loading/Saving support
-----------------------------

 . Add support for 1/4/24 bpp bit PCX files. Currently the MGL will
   only read PCX files that are 8-bpp.

 . Add support for PNG bitmap reading, based on the freely available
   LIBPNG library. This would be very similar to the new JPEG functions
   based on the IJG JPEG library.

 . Add support for TIFF bitmap reading, based on the freely available
   LIBTIFF library. This would be very similar to the new JPEG functions
   based on the IJG JPEG library.

Font Functions
--------------

 . The MGL currently does not have support for scaling bitmap fonts from
   one size to another, so you can only use the size specified in the
   font files on disk. It might be interesting to add a font scale
   function that would scale the monochrome glyphs in the font file
   when it is loaded from disk.

 . The MGL currently includes a bunch of font files that are in the MGL
   1.x font file format, but it can also load fonts in the Windows 2.x
   style font format (standard format used by Windows 3.x, Windows 95
   and Windows NT). A useful project would be to write a font converter
   from the MGL headers and source that would convert the MGL 1.x style
   fonts to Windows 2.x style fonts. With this completed it would then
   be possible to edit any of the MGL fonts with a Windows font editor.

 . The MGL currently only support loading of Windows 2.x fonts in the
   .FNT format which is a single font per file. Normally Windows bitmap
   fonts are distributed in .FON Font Library format with all the sizes
   for that font included in a single file. An interesting project would
   be to add support for Font Libraries to the MGL so that a single font
   of a specified size could be loaded from a specified font library
   file on disk. Of course to make this really useful, the MGL 1.x fonts
   would need to be converted to Windows 2.x format so that the font
   collection can be all converted to font libraries.

 . The MGL currently supports only bitmap and stroke font files, and does
   not support True Type fonts. An interesting project would be to write
   some code that loads and renders a True Type font for the MGL internally,
   so that font can be used as a bitmap font of a specified size.

   This project has actually neen started by an MGL developer, using the
   FreeType library for doing the TrueType font conversions. At this
   stage the code is not integrated into the MGL library proper, so this
   project should be relatively simple to complete.

 . The MGL currently does not support caching of font data in offscreen
   memory when using a VBE/AF hardware accelerated mode. Although the
   MGL_putMonoImage function is fully accelerated by VBE/AF, storing the
   font data in offscreen video memory will provide a big increase in font
   rendering performance on VBE/AF 2.0 drivers that support the new
   PutMonoImageLin functions (and in fact some hardware devices can only
   support this format). Hence an interesting project would be to add
   support for caching the font data in offscreen video memory for ultra
   fast font drawing (if the font is rotated, the cache font would have to
   be rotated also, but the MGL already does this internally).

MegaVision C++ GUI Framework
----------------------------

 . The MegaVision currently has a few minor bugs in the screen update code,
   so an useful project would be to take a look at fixing some of these
   bugs.

 . The MegaVision library currently has classes for Radio Buttons and
   Check Boxes, but those classes have not been completed (no support for
   drawing the text labels for the buttons!). An interesting project would
   be to flesh out the button controls for the MegaVision including these
   and adding support for bitmapped buttons to the library.

 . The MegaVision library currently requires that all user interface
   components be created in code, and does not have a disk based resource
   file format. A useful project would be to create a resource editor
   for MegaVision and a set of routines to load the definitions of the
   resources from disk, allowing user interfaces to be constructed in a
   visual manner.

 . One thing that would make the MegaVision a very powerful GUI library
   is to add support for changing the 'Style' or Look and Feel of the
   GUI library, such as how the windows look, how the buttons look etc.
   It might be possible to change a lot of the UI drawing code to be
   bitmap based so that a different set of bitmaps could be used to
   completely customise the look and feel of the GUI library (great for
   game devlopers who want a GUI that fits in with the theme of the game!).

Game Framework
--------------

 . Add code to the Sprite Manager to allow it to not own the source
   bitmaps so they wont be deleted when it is destructed.

 . Add support for assembler run length encoding routines. We can change
   the code not support any clipping, and to maintain the original bitmap
   as well as the RLE bitmap and draw the original bitmap when clipping
   is on (may be faster). Although clipping may be just as easy.

 . Add code to the Sprite Manager so that we can change the active device
   context and it will automatically figure out how to reload the bitmaps
   into the new device contexts.

Mesa OpenGL Support
-------------------

 . Layer the Mesa rendering functions on top of the MGL 3D rendering
   functions for primitives that are supported. These functions are
   written in assemble and are relatively fast, and would make rendering
   in Mesa quite a bit faster when using the MGL.

 . Get the 3Dfx and S3 Virge accelerated version of Mesa compiled and
   working with the SciTech MGL. It should be possible to implement the
   new DGL OpenGL/DirectDraw bindings interface in these drivers for fully
   integrated fullscreen OpenGL support.

Hardware OpenGL Support
-----------------------

 . Flesh out the support for the MGL 2D rendering and bitmap functions
   using the OpenGL drawing functions. This will then allow the MGL to run
   with hardware acceleration on hardware accelerated OpenGL drivers for
   the 2D MGL functions (like MGL_bitBlt, MGL_drawRect etc).

Enhanced DOS Extender Support
-----------------------------

 . Update the support for the Phar Lap TNT DOS Extender, which can be used
   with the Borland, Microsoft, Symantec and Watcom C++ 32-bit DOS
   compilers. The basic TNT support functions are already implemented in
   the PM/Pro library (full interrupt handling, mouse handling etc). The
   only missing function is PM_mapPhysicalAddr() which maps a physical
   memory address to a linear address. In the early MGL 2.0 beta libraries
   this was done by creating a selector and using that selector in all
   the drawing code, however now the code is purely 32-bit flat linear
   addressing so this function needs to be implement.

   When running under a real DPMI DOS extender the Phar Lap DPMI 1.0
   functions wont work, but you can probably write some code to detect this
   and use the direct DPMI calls that we use for the Watcom C++, Borland C++
   and DJGPP versions of this function (see the GENERIC_DPMI32 section
   of the PMLITE.C module.

Ports to other Operating Systems
--------------------------------

The MGL internally is developed using a combination of C and assembler,
however the MGL can be compiled using a #define NO_ASSEMBLER macro, which
effectively disable all the runtime assembler functions and compiles in
optimized C code equivalents to these functions. For ports to other OS'es
running on the Intel platform, getting the assembler code to compile and
link for that OS would be benefical, but for non Intel CPU's you can simply
use the C only code.

1. Complete the port to the DEC Alpha running Windows NT. The MGL libraries
   have already been ported to the DEC Alpha, however some of the code
   in the MGL (specifically the fixed point math functions) could benefit
   from being re-written to use the DEC Alpha 64-bit multiples in C for
   very efficient fixed point routines. Some of the low level rendering
   functions like blitting might also benefit from a sprinkling of
   Alpha assembler code.

2. Port to the Linux OS. The MGL compiles and links fine with GCC under
   DOS (DJGPP), so it should compile and link just fine with GCC under
   Linux. We also have the OBJ2BFD utility that converts the TASM'ed
   assembler code to COFF, ELF or other formats so that it should be
   possible to compile and link the real assembler code with a Linux port.

   The most complicated part of doing a port to Linux is adding the MGL
   binding functions that usually live in the MGLWIN\MGLWIN.C module (the
   Windows version). These bindings would need to be developed to allow
   for rendering in a window using a X shared memory buffer, as well as
   rendering to a fullscreen display using whatever fullscreen technology
   is available.

   An even better project would be to get support for VBE/AF working under
   the Linux OS, and then you could do fullscreen exclusive modes similar
   to DirectDraw or WinDirect under the Windows environments. VBE/AF would
   take care of all the details of controlling the graphics card, and would
   include full support for 2D acceleration functions.

   A Linux port could also form the foundation of a port to any other
   OS (Intel or Non-Intel) based on the Unix environment.

3. Port to OS/2 Warp. This would be an interesting port, assuming that
   people are still interested in developing for OS/2. I dont know if
   many game developers would care about this, but perhaps IBM could step
   in and do this ;-)

4. Port to the Apple Macintosh OS. This would also be an interesting port.
   The Macintosh is a gamer developers paradise waiting to happen, since
   there are lots and lots of Macs hanging out in peoples homes. Being
   able to cross compile a game for the Mac without any major headaches
   would be a real plus.

5. Port to the Apple Rhapsody OS. This is going to be an interesting OS,
   so it would be interesting to see a port to this, especially the Intel
   version of Rhapsody. Perhaps Apple would be interested in doing this ;-)

6. Port to the BeOS. I dont know much about this OS, but it sounds neat.
   Perhaps a port to the BeOS would be cool, especially since the appear
   to be very focused on OpenGL so it might be a cool game developer
   platform.

7. Port to Silicon Graphics Workstations. Now this would be a killer port,
   especially if there was full OpenGL support in the libraries. With a
   port to SGI boxes, you could do testing and development on SGI boxes
   and then re-compile the code for testing on real PC before deployment.
   Maybe Silicon Graphics would be interested in doing this ;-)

---- END OF PROJECTS.TXT ----